Mobile devices such as cell phones and PDAs come with so-called native applications built in. Native applications are typically pre-installed, cannot be removed, and are ready to run. Some of the applications are always running while others are started by the user via the menu.
Users are able to further customize their mobile devices by loading additional applications (e.g., instant messaging), games, etc. onto these devices. A MIDlet is a Java program that can be loaded onto such a mobile device. In order for a Java MIDlet to be able to run on a mobile device, the device must have an embedded Java Virtual Machine (“Jbed VM”), an execution engine used to translate and execute Java byte-code into native processor instructions at run-time. Application Management Software (“AMS”) on the mobile device manages the downloading of MIDlets and their lifecycle, which consists of discovery of the MIDlet, installation, update, invocation, and removal.
When an application such as a MIDlet is written, it is not necessary to provide for certain tasks common to all programs, such as, for example, drawing icons and maintaining lists of items. Libraries containing these common functions in the form of reusable code can be requested, or called, and loaded during runtime of the application. The Jbed VM interfaces with an application programming interface (“API”), which allows a software application to make such calls to a library during runtime. This relieves programmers from the trouble of rewriting the same code for many of these common functions. The API allows access to these functions without necessarily divulging the source code of the functions or library.
FIG. 1 illustrates a prior art mobile phone platform 10 enabling a JVM 12 and a plurality of other native applications 14. FIG. 2 is illustrates another prior art mobile phone, platform 20 enabling a JVM 12 and a plurality of other native applications 14. As can be seen from both FIGS. 1 and 2, the Java Virtual Machine 12 can be considered simply one of many native applications 14. Even so, there is a lack of unity between a Native Application platform 16 and the platform of applications (MIDlets) running in the JVM 12.
There exists a lack of unity between the world of the native platform running native applications and the parallel world of the Jbed VM running MIDlets within the native world. Integration of the worlds could be problematic since native applications and libraries are often written languages other than the Java programming language (such as C and C++). Additionally, multitasking a plurality of native and MIDlet applications led to problems with, for example, unfair resource allocation, misbehavior of one application affecting another application, inter-task communication, etc. Furthermore, in mobile devices where both a native graphical user interface (“GUI”) and Java GUI were running, enormous customization efforts would be required on the part of developers and the end user could experience an inconsistent look and feel in both the appearance and execution of various applications.